Digital compressed video based on the Moving Picture Experts Group (MPEG) set of standards has become the predominant choice for delivering and storing broadcast-quality digital video content. The MPEG systems layer multiplexes several compressed elementary streams (video, audio and data) into a single transport stream (TS). The transport stream consists of a sequence of transport packets, suitable for storage and network transmission of the encoded program. Several, possibly interleaved, TS packets put together comprise a single compressed frame of an underlying elementary stream. The header of a TS packet contains an identifier to indicate the specific elementary stream that contributes to the payload of the packet. In typical transmission networks, multiple TS packets are further aggregated into a single network packet. In streaming content delivery applications (e.g., live TV, video on demand (VoD)), an integral number of TS packets are encapsulated into a User Datagram Protocol (UDP) or Real-time Transport Protocol (RTP) packet, and the departure time of each packet is tightly controlled in order to ensure that the receiver buffer never overflows on one hand and the receiver never starves for frames on the other. The header of an RTP packet contains a timestamp that denotes the relative departure time of the packet at the sender. In download-based content delivery applications (e.g., many examples of Internet-based video delivery), the sequence of TS packets is treated as a file, and pieces of the file are encapsulated into a Transmission Control Protocol (TCP) packet. The departure time of each packet is primarily controlled by the TCP feedback mechanism from the receiver. In addition, a bandwidth limit may be placed by the sender in order to conserve network resources and enforce fairness amongst the different outgoing streams. Functions such as precise departure timing and bandwidth limiting are performed by the scheduling logic of the content delivery server.
Depending upon the application, content scheduling may be based on the embedded timestamps in the transport or network packets, on the inherent bit-rate of content, or on a configured bandwidth limit. For example, MPEG encoders embed a time-base referred to as a Program Clock Reference (PCR) in the TS packet header. A PCR value is included in a subset of TS packets, and denotes the relative departure time of each packet at the encoder. A streaming scheduler may use the embedded PCR values to determine the exact departure time of each packet from the content delivery server. In open-loop networks with no global clock, the PCR may also be used by the decoder to lock its clock to that of either the server or the original encoder of the content. If the content is encoded as a constant bit-rate (CBR) transport stream, a streaming scheduler may instead use the encoded bit-rate to periodically dispatch packets, using a scheme such as Shaped Virtual Clock. Similarly, a download-based scheduler may use the configured bandwidth limit to place an upper bound on delivery timing. In either case, the scheduler may be implemented as a Just-in-Time (JIT) scheduler, wherein packets depart exactly at the instants dictated by the delivery timing logic, or as an Earliest Deadline First (EDF) scheduler, in which the delivery timing is merely used to establish a sorted departure order for the outgoing packets. It is noted that different content delivery applications place different requirements on the delivery timing of the served streams.
FIG. 1 illustrates a typical video-on-demand server 100 found in the prior art. Video content is ingested into the server 100 as files 104, and stored in a media storage device 106. The source 102 of content may be a folder fed by a satellite receiver, or may be another content server. Files 104 may be ingested offline under the command of network management software (not shown) or in real time based upon a receiver request for content. The server 100 consists of multiple line cards 110a-b connected to its network interfaces, each of which is controlled by a scheduler 114a-b (the shaded triangles in FIG. 1) responsible for dispatching network packets to the receivers 118 via a communications network 116. For each served stream, the scheduler 114a-b fetches the content payload from the media storage device 106, assembles it into UDP or RTP network packets, determines the delivery time of each packet, and places each packet on the interface to the network 116 at the determined time. In this configuration, there is typically no feedback from the receivers 118. For CBR video streams, the departure time for each packet may be computed using the packet size and the encoded bit-rate of the content file. Alternatively, for CBR or variable bit-rate (VBR) video streams, the departure time may be computed using the embedded PCR values in the TS packets. A high-fidelity system clock 112 is used by each scheduler as the source of time.
FIG. 2 illustrates a typical live video server 200 found in the prior art. The purpose of this configuration is to process live channels and serve the incoming content with minimal delay. Such processing (not shown in the figure) may include replicating each incoming channel into multiple copies, e.g., to convert broadcast feeds into personalized or “group-cast” streams, converting a multi-program TS into several single-program TS, e.g., as required by cable Switched Digital Video (SDV) applications, converting CBR streams to and from VBR streams based on receiver requirements, splicing advertisements into the incoming channels, de-jittering the channels, or any combination thereof. In such applications, video content is ingested from one or more content sources 202 into the server 200 as real-time channels 204 and stored into a transient buffer memory 206. The processing described above may be performed prior to storage or upon retrieval from storage during delivery. For each served stream, a scheduler 214a-b (shown as the shaded triangles in FIG. 2) fetches the content from the transient memory 206, assembles it into UDP or RTP packets, determines the delivery time of each packet (based on PCR or CBR bit-rate), and places each packet on the interface to the network 216 at the determined time. Since channels 204 are ingested in real time from multiple content sources 202, assuming there is no global clock that synchronizes the system clocks of each source with that of the server, additional provisions are included to ensure that the buffer memory 206 does not overflow or underflow due a rate mismatch in clocks. Typically, this is done by implementing a phase lock loop (PLL) 220a-b for each incoming channel 204, using the embedded timing information in the video content. Each such PLL is used to adjust the clock 222a-b that drives the scheduler 214a-b for each served stream derived from that channel 204.
In principle, Internet content delivery scheduling is similar to video-on-demand scheduling. For example, in Adobe Real Time Messaging Protocol (RTMP) streaming, embedded timing information is used to control delivery timing of each packet. In another example, in HTTP progressive download applications, a nominal bit-rate configured by the server software is used by the scheduler to place an upper bound on delivery timing. In most Internet content delivery, the network operates in a closed-loop fashion, wherein TCP feedback from the receiver may block the delivery of packets. To accommodate such feedback, the scheduler in such servers uses the state of the TCP window to determine whether a stream is currently eligible for dispatch, and performs the delivery timing function only on currently non-blocked streams.
In some video delivery applications, there is an additional requirement to speed up (or burst) packets, with respect to their determined delivery time, at some intervals specified by the server software. For example, primarily in IP-based live television, such bursts may be used whenever a receiver changes channels so as to facilitate an “instant” channel change feature (as opposed to waiting for the next anchor frame to arrive and for the decoder buffer to fill), or may be used at splice points for ad insertion, in order to compensate for the difference in decoder buffer fullness at splice points and achieve a seamless splice. The same kind of bursting technique may also be used in HTTP progressive download applications, at the beginning of the stream, to ensure that the decoder buffer stays ahead of the required display time of each frame, thereby preventing buffer underflow. To provide for such a feature, a scheduler typically weights the determined delivery time of each packet in the specified burst interval, with a specified burst factor. This weighted delivery time is then used by the scheduler to govern packet dispatch.
Such diverse applications are typically handled by different server equipment, each implementing a scheduler suitable for the respective application. Stored content delivery is handled by dedicated VoD servers in cable networks, most of which only support bandwidth-based CBR delivery, and is handled by web servers or proprietary streaming servers (e.g., for RTMP) in the Internet. Live content processing and delivery is handled by specialized equipment such as groomers and splicers. There is an emerging trend in the industry towards converged video delivery to multiple screens. In such a world, users receive live and on-demand content all via personalized streams. Furthermore, users expect to receive such content on multiple devices, each with different capabilities (e.g., TV set-top boxes that require streaming service and PCs that prefer progressive download) and connected to different networks (e.g., HTTP/TCP-based Internet and UDP/RTP-based managed networks). It would be cost prohibitive to deploy specialized server resources separately for each delivery application, all dimensioned to handle the peak request load from the users, especially since most users do not expect content delivery of all types simultaneously. There are no adequate provisions in the prior art for building a converged delivery server that simultaneously supports multiple delivery types without expensive replication of server resources (e.g., one server card for on-demand HTTP download and another for live TV streaming).